1. Field of the Invention
This invention relates generally to methods, machine readable media and apparatus for use in connection with testing, evaluating and debugging generally opaque intellectual property (“IP”). More specifically, this invention relates to a technique for providing limited visibility of nodes, signals and other information in encrypted IP.
2. Description of Related Art
In the field of electronics, various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of custom configurations for programmable integrated circuits. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), complex programmable logic devices (CPLDs), and a wide variety of other logic and memory devices that may be programmed. Often, such PLDs are designed and programmed by a user with an electronic design automation tool that takes the form of a software package. A wide variety of these devices are manufactured by Altera Corporation of San Jose, Calif.
Modular design can significantly accelerate the implementation of a system design in electronic devices. A user (also referred to herein, as appropriate, as a “customer” and/or “system designer”) can partition a design into logic blocks, for example wherein each logic block provides a specific functionality. These logic blocks can be implemented on the target device using cores of intellectual property (IP). IP may, for example, be a high-speed serial interface (HSSI), a digital signal processor or other microprocessor, ALU, memory, or a multiplier. “IP” may also be referred to herein as an “IP block” or an “IP core,” as appropriate and as will be appreciated by those skilled in the art. These terms are generally interchangeable for purposes of the present invention, unless otherwise indicated specifically or contextually.
The “IP designers” discussed herein are the individuals who develop and create IP that can be used in various electronic designs. This IP is designed to be plugged into designs and used, more or less, as building blocks for larger systems. An electronic system in many cases comprises logic designed by system designers, where the designed logic incorporates one or more pre-designed blocks of IP. Such IP is typically designed by different individuals than the designers of the overall system. When the IP is designed by a different company than the system in which the IP is used, the company providing the pre-designed IP typically has an interest in keeping the implementation details of the IP a trade secret and discouraging its unauthorized use.
EDA tools provide system designers with automated tools for designing and verifying circuit designs. EDA helps create, analyze and edit proposed electronic designs for purposes of simulation, prototyping, debugging, execution, computing, etc. EDA also can be used to develop systems that will use one or more user-designed subsystems and/or components in connection with pre-existing IP provided by another party.
In the course of generating an electronic design, simulation, timing analysis and/or other techniques may be used to debug the electronic design. During the course of a debugging simulation, a designer monitors various signals at nodes in the electronic design. Being able to identify signal behavior at specific nodes in the proposed electronic design allows the system designer to track down the source of errors or other problems and/or otherwise gather and use information regarding the behavior and operation of the proposed design.
As mentioned above, IP designed by one entity often is delivered to system designers as an encrypted netlist, encrypted RTL, or some other “opaque” version of the IP, as will be appreciated by those skilled in the art. IP whose implementation details are not readily visible to users will be referred to as “opaque” IP herein. IP can be provided in several forms: as drop-in blocks that include all of the information needed to realize the design, such as providing complete mask-level realization data for an ASIC core, as fixed functions that may or may not contain complete mask-level realization data, or in a parameterizable form that may or may not incorporate all of the data needed to realize the design. In the case of Altera IP, it usually is supplied as parameterizable RTL or netlists that are synthesized on the customer's desktop. No mask-level realization data is supplied.
Since the IP is essentially opaque to the user, it is not practicable for the user to probe internal nodes (for example, key registers, signals and state machines) to see the IP's state during the system debugging process carried out in simulation and/or running in hardware. This lack of visibility into an IP core can impede the system design and debugging process and can leave the user wondering if a problem is due to errors in the portion of the system the user designed or a problem with the IP.
Earlier debugging and analysis techniques and systems (which have not covered the debugging of opaque IP) have added features to the proposed electronic design (for example, in the RTL code) by synthesizing debugging logic into the design itself. These added features and/or circuits change the proposed design by building the diagnostics into the system. Therefore, debugging done inside the hardware using these types of techniques actually leads to changes the design, which is not always desirable.
Another approach to debugging a hardware device within a working system is to use a separate piece of hardware equipment called a logic analyzer to analyze signals present on the pins of a hardware device. Typically, a number of probe wires are connected manually from the logic analyzer to pins of interest on the hardware device in order to monitor signals on those pins. The logic analyzer captures and stores these signals. However, the use of an external logic analyzer to monitor pins of a hardware device has certain limitations when it comes to debugging such a device. For example, such an external logic analyzer can only connect to and monitor the external pins of the hardware device. Thus, there is no way to connect to and monitor signals that are internal to the hardware device. Unfortunately, when programming a hardware device, it is useful to monitor some of these internal signals in order to debug the device. One solution to this problem has been Altera's SignalTap, which is well known to those skilled in the art.
Although some hardware devices may come ready made with some internal debugging hardware, this debugging hardware typically is hardwired to route specific internal signals and cannot be readily adapted by a user who wishes to look at other signals. Because a programmable device is by its very nature a device that a user is attempting to program to perform a particular function, it is important to the user to be able to specify signals to be monitored, as well as trigger signals and trigger conditions in order to efficiently debug any particular device. Further, creating an electronic design for a programmable device is an iterative process that requires creative debugging by a user who may wish to monitor various signals, and who may change his mind on which signals to monitor fairly frequently in the course of debugging a PLD within a system. Known external and internal logic analyzers do not provide this flexibility with regard to generally opaque IP.
Techniques that permit thorough development and evaluation of digital systems and devices by system designers and other users, while maintaining proprietary IP protection (for example, by IP block opaqueness), would represent a significant advancement in the art. Moreover, it would be a further advancement if these techniques were adaptable to allow an IP designer to enable visibility and assign meaningful aliases for one or more useful nodes within opaque IP and to allow the system designer to select certain of these visibility-enabled nodes in debugging and other settings and contexts.